It follows a small list of known open issues.
A week ago, I was contacted by an hungarian guy (Krisztian Steber thank you
again) for some problems during the analysis of his sources.
After about a week, he discovered that it was something about his system
regional settings (hungarian + sort order = default).
It seems that the case-insensitive string comparation fails when meets
something like 'cs', since in hungarian language 'cs' a 'letter' different from
'cS'...
This was the problem, Horodruin uses the lower-case file name to locate items
into other sources.
The funny thing is that these regional settings have some problem into win2k setup process too.
From v2.0.176.0 this problem should be fixed.
The taken approach is to replace all case insensitive string compare function
with the normal string compare one but using always the lowercase version of the
string.
It may happen that the program fails to validate a source.
With v1.0.68.0 this should happen only when you share an empty volume in a network (for example: "\\myPC\CDWRITER").
The problem occurs because the program validate the source folder in 2 steps:
Well I think that there are at least 2 walkarounds. The first is simply copy something into this disk (the 2nd test doesn't fail anymore), the second is mapping the network shares as a drive.
From v1.0.70.1 this problem should be fixed.
The taken approach is to peek into the source to get the first item. In
case of failure (source is empty) it looks for system error codes to see if there is no file or it's a bad path.
A friend of mine, has reported to me several "access denied" during the update of the 'last updated' time-stamp at the end of synchronizations.
After a short investigation we have discovered that it was caused by the copy
engine operation sequence.
It was trying to set source file attributes and then to restore the timestamp.
This is a problem, with a file with read-only attribute on.
It leaves the file updated but with a wrong time-stamp. A very annoying behaviour from the next synchronization, because it may
overwrite a newer file with a good time-stamp.
The things are lightly better when using the temp file on a target with read
only attribute. At the end of the synchronization, the target isn't
updated at all.
This is caused because the engine fails to delete the original old file before
renaming the temp one.
From the v1.0.73.1 this problem should be fixed.
The approach taken now is slightly changed.
Now when temp files are used, the attributes are resetted, and then the original
old file is deleted.
When they aren't used, the time-stamp is updated and then the attributes are
set.
Changing the attributes doesn't touch file's 'last updated' time-stamp.
When the program is started, an error pops up, and it states that one of the following DLL is missing:
borlndmm.dll
cc3260mt.dll
rtl60.bpl
vcl60.bpl
The problem here seems that you haven't one of the needed VCL6 Runtimes
Libraries.
The most common case is that you have skipped the setup screen that advice you
may have needed them.
Install the VCL 6 Runtime Libraries, and the program should now run fine.
You can download them from the program site (see contacts).
Somewhen it occurs that some synchronization errors aren't collected into results window. Into my own case it happens that I try to write a single file on a closed CDR, and sometimes the synchronization went fine.
In a first time I think about some sort of bug into the copy engine, but I have
discovered that it was a strange race condition.
I have discovered that sometimes the output thread could generate an error
before the calling class (and the results collecting engine) overcasts the virtual
entry point (method).
In this case, the virtual method is still the base (empty) one.
From the v1.1.81.0 this problem should be fixed.
Now the output threads now wait for the calling class has been fully initialized
before doing anything else.
The default behaviour during a source analysis, is to count all its file in a
first time, and analyzing them in a second time.
This approach works fine with the local devices because most of the file system
data used is cached by the system the first time.
With network sources this is not true, the first step data aren't cached and
the second step has to asking them again.
This has 2 major drawbacks. The first one is that the network traffic is
doubled, while the other is that the second step lasts exactly like the first
one.
I have noted it during a 14000-15000 items' analysis. The speed doubles
when I disable the first step (from 125 to 61 seconds).
The file count is guessed by keeping the greater source item count already
processed. The only drawback I have found is that starting the analysis
with a network source produces a not-so-fine effect on the progressbar and the
stats label. Really a small price for such enhancement.
From the v1.1.88.0 this problem should be seriously reduced.
Probably this will not be the final approach the program will take to face the problem, but actually we will see what will need of a further improovment.